-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LIT-2841 - Remove ipfs-http-client
and create encryption APIs for composition with any storage layer
#427
Conversation
@joshLong145 I went ahead and made the
|
684fc79
to
34a0ec0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving as the polyfill has been tested.
…s-sdk` - Remove `@ts-nocheck` pragma - Fix two test cases that were being called without `cert` as an argument (error was hidden by `@ts-nocheck` pragma) - Fix unnecessary TextEncoder/TextDecoder injection -- this is done by our jest config - Use `cross-fetch` to ponyfill fetch - Remove unused imports
…ss-fetch` and remove soon-to-be-unused `ipfs-http-client` and `ipfs-unixfs-importer` deps
…fetch (it's done in `lit-node-client-nodejs`, which this wraps!)
… with `cross-fetch/polyfill` usage. Squelch ESLint errors in global hackery.
… associated tools.mjs command
…ed `ipfs-http-client`
…-fetch` for POSTing data to Infura
…ncrypt/decrypt with to/from Json encrypt/decrypt - Removed `...IpfsProps` and `...IpfsPayload` interfaces - Defined `...JsonProps` and `...JsonPayload` interfaces - Used `MultipleAccessControlConditions` interface in a bunch of places where we had duplicated the entire interface, comments and all, in-line in other interfaces. - Used `EncryptRequestBase` as the basis for the new Json interfaces instead of duplicating the contents of that interface in-line - Clarified `sessionSigs` from being an `any` type in a few interfaces, to being a `SessionSigsMap` type.
…Json, and remove now-unused ipfs validator - Also eslint --fixed the file, and replaced an `any` type on `AuthMethodValidator` with `AuthMethod` type. - Removed unused `decryptToZip` validator that used an `any` type; that method actually just uses the `decrypt` validator anyway
… from ipfs methods with `encryptoToJson` and `decryptToJson` methods
…Ipfs` and `decryptFromIpfs` with our new to/from JSON methods
…handling throw if not `file` or `string`
… for `LitContracts` - No longer logs huge arrays of numbers that represent the ABIs - ESLint --fix'd the file
…properly based on `parsedJsonData.dataType` arg 🎉
…h `string` and `file` be passed to `EncryptToJsonValidator`
…ecrypting from JSON strings including metadata
93cdeb3
313a163
to
93cdeb3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Description
Overview
This PR removes a problematic dependency that also happened to be very large code and dependency-wise -
ipfs-http-client
. We were using this in a single place in our SDK as part of a 'nice-to-have' function. Unfortunately, the package has issues with bundling in multiple environments and brings a very large # of dependencies into our bundle that a lot of our users never actually needed.The API for the method that used this dependency was also problematic; it was hard-coded to use Infura credentials and endpoints, and Infura has disabled the ability to create IPFS-enabled API keys since November of 2023. Rather than re-work the API to allow arbitrary providers, authentication, etc, we decided that it would be more flexible for consumers, and better for the size of our bundles and compatibility in multiple environments, to remove the dependency and instead provide some functions that are un-opinionated about where the encrypted data is going or coming from.
Anyone who would like to encrypt to/from IPFS can simply call these new methods and then use the client of their choice to put the data in IPFS.
Even better, anyone who wants to encrypt/decrypt somewhere other than IPFS, but without compressing the data using our existing APIs that encrypt into ZIP files with metadata stored inside the ZIP archive can use these same methods to work with any other arbitrary data store they want to use.
Before this change, the only code that would wrap up the encrypted data with the metadata required to easily decrypt it later was the 'encryptToIpfs()' code which stored the encrypted data and metadata in the same JSON blob, always on IPFS, or
encryptFileAndZipWithMetadata()
code which stored the metadata as a separate file from the encrypted data in the ZIP archive and only worked with files (not bare strings).Changes:
encryptToIpfs()
anddecryptFromIpfs()
methods inencryption
, which were also exported fromlit-node-client
encryptToJson()
anddecryptFromJson()
inencryption
, and export those methods fromlit-node-client
encryptToIpfs()
anddecryptFromIpfs()
methods produced and consumed.Fixes:
fetch
, where we were mutating global fetch even if it was previously defined.cross-fetch
to handle this polyfill, which is friendly to environments where it is already defined -- and was already part of our dependency tree due to other dependencies we already rely on.node-fetch
direct dependency now thatcross-fetch
is being used to polyfill.ipfs-htttp-client
dependency, which was causing bundling errors in mixed environments (NextJS)Internal changes:
Type of change
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist: